1. Field of the Invention
The present invention relates to a program developing apparatus, a program developing method and a computer readable medium for efficiently maintaining software, such as firmware used in an embedded device having limited computer resources such as a memory and a processor, while retaining runtime performance.
2. Related Art
In development of firmware used in an embedded device having limited resources, since performance requirements are highly prioritized, the development is often performed giving priority to execution efficiency, such as performing the development in a low-level language and performing an implementation at the sacrifice of nonfunctional quality for increasing software maintainability.
The term “Resources” herein means the performance or the amount, of a memory or processor. For example, in the development of the firmware for the embedded device in which these are extremely limited, the implementation is often performed with a high regard for the performance. In other words, sometimes coding is performed directly in a machine language. Also, even if a high-level language such as C is used, an implementation with a module group having low cohesion and high coupling is often seen, which is performed at the sacrifice of nonfunctional requirements such as portability, maintainability and readability. When addition or correction of functions is attempted with respect to such an implementation, it is difficult to forecast which part is appropriate to be corrected and the like, and it is frequently seen that many man-hours are required or defects are often caused.
Incidentally, the coupling and the cohesion are examples of measures for evaluating quality of the software. The coupling is a measure for measuring strength of linkage and interdependency among components of a program. From the viewpoint of the software maintainability, low coupling, that is, less interdependency of the components is regarded as preferable. It is because when maintenance tasks are performed with respect to the components having high coupling with others, it is necessary to consider effects on other components. As an example of the coupling measure, a measure referred to as “CBO” of CK metrics can be quoted.
On the other hand, the cohesion is a measure for measuring scale of cohesiveness of functions in the components of the program. As is expected, from the viewpoint of the software maintainability, high cohesion, that is, large scale of cohesiveness of the functions is regarded as preferable. A component having low cohesion means a state in which multiple roles or functions are overlapped, and it means that an attempt to correct one function in the component is likely to affect other functions or roles included therein. As an example of the cohesion measure, a measure referred to as “LCOM” of CK metrics can be quoted.
As described above, there have been various problems with the addition or the correction of the functions in the implementation at the sacrifice of the nonfunctional requirements. However, conversely, in an implementation having appropriate redundancy which is regarded as ideal in terms of software engineering, there has also been a problem in which flexibility in performance control, in which delicate performance requirements required for the firmware can be accommodated, is limited and the performance is not achieved.
An essential solution for such problems has not been proposed so far. For example, many source code analyzing techniques for reading and solving complex source codes have been proposed. Slicing technology and the like have been established as techniques for decomposing functions in the source code, and a research for using this to convert the source code into a state of high readability has been also performed. However, this is one-way conversion, and can only provide a function only for reading and solving the source code.
Also, many techniques for conversely generating codes having high execution efficiency from the codes having high readability have been proposed, such as a compiler optimization technique. However, notwithstanding, mechanical optimization has limitations and does not come up to a result of performing fine adjustment at a source code level by human. Conversely, since there is also a case where the development in which there is no mistake in debugging or function verification can be performed rather by performing extreme optimization at the source code level without using a compiler optimization option, the compiler optimization technique is a technique which is not so appropriate.
In addition, there is an approach for increasing the maintainability by previously combining pieces of the code having high modularity, that is, having high cohesion and low coupling (for example, U.S. Pat. No. 6,694,505). However, primarily, this is such a technique that cannot be used in the case of low modularity, and is not appropriate for the problems as shown herein. Moreover, there is also such a technique that improves productivity by visualizing an architecture of target software and presenting it (for example, U.S. Patent Publication No. 2004-0031015). However, this cannot be applied to the case where there is no explicitly arranged architecture as intended this time, either.
Basically, development of resource-limited software significantly depends on a result of manual optimization at a source code level. There is a problem in which a source code optimized in this way has extremely low maintainability, and it has been very difficult to perform maintenance, not only for a third party but also even for an author of the original in some cases.